1. Field of the Invention
The present invention generally relates to network-connected devices. More specifically, the present invention relates to providing secure communications for multiple network-connected devices from different vendors or manufacturers.
2. Description of the Related Art
The phrase “internet of things” refers to network-connected devices that may receive inputs from a computer network and/or transmit outputs to the computer network. For example, a network-connected “internet of things” lightbulb might be controllable from a user's smartphone device, so that a user could turn his/her lights on or off without having to push a physical light switch. Similarly, a network-connected “internet of things” automobile might provide gas mileage data to a user's smartphone. Other “internet of things” devices may be thermostats, smart watches, or washing machines.
Due to decreased costs and sizes of computer components and wireless network connection modules, more and more network-connected “internet of things” devices are being produced. As production of network-connected “internet of things” devices has increased, several major problems have emerged: trust, identity, and interoperability.
Some network-connected “internet of things” devices can communicate with a user's mobile device through either a potentially untrustworthy non-secure internet gateway system 130 through a public internet connection, or alternately, through a non-secure local gateway system 140 with improper identity verification.
FIG. 1A illustrates a prior art architecture for communications between a user mobile device and a set of network-connected devices through a non-secure internet gateway. Some network-connected “internet of things” devices (e.g., a particular network-connected device 160 produced by a particular brand or manufacturer such as “Brand X”) can communicate with a user mobile device 100 through an internet gateway system 130 using a connection that goes through the public Internet 150. The user mobile device 100 must often be produced by a particular brand (e.g., “Brand Y”) that is designed to communicate with devices 160 of “Brand X” (which may in some cases be the same brand as “Brand Y”) through a mobile software application (“app”) 110, generally also produced by the same “Brand X” that produces the devices 160.
The user must blindly trust the internet gateway 130's managing entity (e.g., typically the same “Brand X” that produced the device 160), which could potentially view and/or alter the user's communications between the user mobile device 100 (e.g., originating from “Brand X” mobile software app 110) and the user's network-connected “internet of things” devices 160.
This could allow the internet gateway 130's managing entity (e.g., “Brand X”) to track the user's actions and whereabouts (e.g., by tracking when the user turns lights on or receiving a location from a user's vehicle) of even health data about the user. The internet gateway 130's managing entity (e.g., “Brand X”) could intentionally sell or give a user's personal data to a third party, or could unintentionally leak this data to a third party via a compromised connection (e.g., man-in-the-middle attack at connection 170, connection 175, or connection 180) or a compromised machine (e.g., malware at the non-secure internet gateway 130). The non-secure internet gateway 130's managing entity (e.g., “Brand X”), or a third party accessing the internet gateway 130 or its various connections (e.g., connection 170, connection 175, or connection 180), could even potentially control the user's network-connected “internet of things” devices 160 themselves by transmitting commands appearing to come from the user mobile device 100 through the internet gateway 130. Such third party control could be annoying (e.g., turning off lights when the user is home), wasteful (e.g., turning on lights when the user is not home), property-damaging (e.g., flooding a washing machine or overheating an oven), or potentially life-threatening (e.g., causing the user's vehicle to swerve).
Typically, a non-secure internet gateway 130 as depicted in FIG. 1A (e.g., managed by “Brand X”) is not designed to function with network devices 160 from brands or manufacturers other than the brand or manufacturer of the internet gateway 130 (e.g., “Brand X”). The Brand X internet gateway 130 typically communicates with any connected network-connected devices 160 (e.g., connection 180) using proprietary protocols or even connection types (e.g. proprietary cables). Thus, the Brand X internet gateway 130 cannot be used to control an ecosystem of network-connected devices 160 by multiple brands or manufacturers.
FIG. 1B illustrates a prior art architecture for communications between a user mobile device and a set of network-connected devices through a non-secure local gateway. Some network-connected “internet of things” devices 160 can communicate with a user's user device 100 through a local gateway 140 (typically produced by the producer of the device 160, such as by “Brand X”) located within a private network without using an internet gateway 130 accessible via a public internet connection. This means that communications between the network-connected “internet of things” devices 160 and the local gateway 140 (e.g., communications via connection 185) are private network communications, though the communication between the user device 100 and the local gateway 140 may still travel through the public internet (e.g., connection 190) if the user is not connected to the same private network.
The approach of FIG. 1B is problematic because it cannot scale and it cannot guarantee the identity of client requests. In particular, implementing Secure Socket Layer (SSL) for communications between the user device 100 and the local gateway 140 can be problematic, particularly when the user device 100 is outside of the private network (e.g., use case 105 of FIG. 1B, connection 190).
A first method of implementing SSL in the context of connection 190 of FIG. 1B is to install and manage certificates using a certificate authority. A major problem with this approach is that this does not scale and is not manageable at a consumer level. The certificates might only be authorized temporarily, costs associated with the certificate authority might have to be paid by the consumer, and/or management operations may have to be performed by the consumer.
A second method of implementing SSL in the context of connection 190 of FIG. 1B is to use self-signed certificates from the local gateway 140 and subsequently get those certificates to clients. Such self-signed certificates are not as secure as certificates issued by certificate authorities, however. Further, use of self-signed certificates in this manner locks the local gateway into connecting with certain devices, excluding the ability to develop an ecosystem with multiple network-connected devices made by multiple brands/manufacturers.
A third method of implementing SSL in the context of connection 190 of FIG. 1B is to use self-signed certificates while clients ignore signature validation. This is almost entirely non-secure.
The connection 190 otherwise transfers communications without the use of SSL, which is non-secure.
Because SSL is not feasible to reliably implement while maintaining interoperability, the connections of FIG. 1B cannot guarantee the identity of senders of communications to recipients. Thus, if the user mobile device 100 sends a communication to the local gateway 140 (e.g., to turn on a network-connected light bulb), a malicious party can compromise the connection and perform a man-in-the-middle attack or a replay attack. Thus, the malicious party could view or change the user's command or trigger a command at a different time.
Typically, a local gateway 140 as depicted in FIG. 1B (e.g., managed by “Brand X”) is not designed to function with network devices 160 from brands or manufacturers other than the brand or manufacturer of the local gateway 140 (e.g., “Brand X”). The Brand X local gateway 140 typically communicates with any connected network-connected devices 160 (e.g., connection 180) using proprietary protocols or even connection types (e.g. proprietary cables). Thus, the Brand X local gateway 140 cannot be used to control an ecosystem of network-connected devices 160 by multiple brands or manufacturers. Such interoperability issues can make communication with inconvenient multiple network-connected “internet of things” devices inconvenient, slow, and cumbersome for a user. This may also force a user to be locked into a single brand or manufacturer or network-connected “internet of things” devices or mobile devices, potentially limiting the user's choices and functionalities and forcing the user to pay more to buy devices by a particular brand or manufacturer.
There is, therefore, a need in the art for an improved “internet of things” ecosystem for securely controlling a variety network-connected “internet of things” devices from a control point of the user's choice.